每天寫文除了寫文本身很花時間以外，想題目我覺得也很花時間。還好，今天的題目剛好昨天就想好了。可喜可賀。今天就來聊聊 MVP 和 Product，也會把一半的重點放在昨天提到的問題「技術債是可以不還的嗎？」這件事上。

Product，也就是產品，這名詞應該比較沒有疑慮，以軟體業這行，簡單來說當然就是要拿去賣的軟體。那什麼是 MVP 呢？MVP 是 minimum viable product 的縮寫，用中文來說就是最簡可行產品。顧名思義，MVP 就是可能只有預想中產品的部分功能，但確恰好可以表達該產品核心概念，所以說是最簡可行產品。為什麼不要直接做 Product 呢？因為直接投入研發的成本是較高的，若是這個功能或特色其實不受市場歡迎，那麼這些成本就會變成打水漂。所以就有了成本比較低的 MVP，先用 MVP 拿去市場做驗證，若是可行就可以做成 Product 正式拿去賣，若是不行就及早收手改做下一個 MVP，避免資源浪費在沒有價值的產品上。

那為什麼 MVP 研發成本會比較低呢？正如前面所述，MVP 只會含有部分功能，一些比較無關緊要的功能就會選擇先不做，比如說登入功能只有支援帳號密碼，不支援OAuth，甚至連忘記密碼等功能都沒有、又比如說，在業務功能上，只做好具重要的部分，就像是音樂播放器只做好播放功能，還不支援推薦歌曲。在界面上可能也會先用現成的框架與配色，而不會做出特別的設計。諸如此類，先只實作最核心的功能，確定這個特色是受到市場青睞的，再正式投入研發。

另外，欠下技術債也是 MVP 研發成本低的原因。除了因為 MVP 的使用者少，比較不用先考慮的效能問題，或是先不考慮未來的可擴充性，所以不用特別客製化好的架構外，另一個重要的原因就是 MVP 很常是驗證完市場就封存的專案，並在展開下一個 MVP，要趕緊找到商機，搶在對手前面推出產品。如此的替換率高、趕時程，程式設計師寫出來的程式碼也不會被稱為優美，甚至充滿了各種壞味道，就因為知道這個專案會被封存，才能比較放心的欠下這一卡車的技術債。

沒錯，到這裡就呼應了昨天尾聲的問題：「技術債是可以不還的嗎？」。事實上 MVP 就是一種可以考慮不還技術債的情境，因為這個專案在完成他的任務後就不會再繼續維護了，是屬於生命週期較短的專案，而當軟體不再被使用時，欠下的債理所當然也就不用還了。MVP 是如此，而舉凡在生命週期較短的專案中欠下的技術債，都是屬於可以考慮不還的，畢竟耗費時間在重構上，可能軟體都已經結束階段性目的或是市場了。有些情況，就是公司必須不斷搶在對手前面推出產品，但這些產品的生命週期都不常，可能賺完第一波，後面的效益就不大了，公司就會放棄這個產品，往下一個標的前進。如果這時候還跟老闆說要花時間把產品重構，那老闆大概會對你大聲咆哮，說你搞不清楚狀況。

但是，事情不一定都會這麼理想。雖然可以因為是 MVP 所以欠下一屁股技術債，但最怕的就是老闆因為 MVP 大受好評，就乾脆當作產品來賣了，一旦這個決策落實了，就會是研發團隊噩夢的開始。所以老闆和研發團隊都必須理解 MVP 和 Product 的差別，以及現在研發的是哪個。若是 MVP 驗證得到良好的回饋，要推出相關產品，就必須讓研發團隊基於驗證得到的結果，再寫一個具有可維護性的 Product，而不是拿現成的 MVP 來用。不然好不容易得到的回饋，卻因為直接拿 MVP 來用，導致後面 Bug 叢生、效能低落、研發成本過高，讓市場失望、搞砸信譽，實在是功虧一簣。